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Report from the Smart Object Workshop 
Abstract 


This document provides an overview of a workshop held by the Internet 
Architecture Board (IAB) on ’Interconnecting Smart Objects with the 
Internet’. The workshop took place in Prague on 25 March 2011. The 
main goal of the workshop was to solicit feedback from the wider 
community on their experience with deploying IETF protocols in 
constrained environments. This report summarizes the discussions and 
lists the conclusions and recommendations to the Internet Engineering 
Task Force (IETF) community. 


Note that this document is a report on the proceedings of the 
workshop. The views and positions documented in this report are 
those of the workshop participants and do not necessarily reflect IAB 
views and positions. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Architecture Board (IAB) 
and represents information that the IAB has deemed valuable to 
provide for permanent record. Documents approved for publication by 
the IAB are not a candidate for any level of Internet Standard; see 
Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6574. 
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Les 


Introduction 


The Internet Architecture Board (IAB) holds occasional workshops 
designed to consider long-term issues and strategies for the Internet 
and to suggest future directions for the Internet architecture. This 
long-term planning function of the IAB is complementary to the 
ongoing engineering efforts performed by working groups of the 
Internet Engineering Task Force (IETF), under the leadership of the 
Internet Engineering Steering Group (IESG) and area directorates. 


Today’s Internet is experienced by users as a set of applications, 
such as email, instant messaging, and services on the Web. While 
these applications do not require users to be present at the time of 
service execution, in many cases they are. There are also 
substantial differences in performance among the various end devices, 
but in general end devices participating in the Internet are 
considered to have high performance. 


There are, however, a large number of deployed embedded devices, and 
there is substantial value in interconnecting them with the Internet. 
The term "Internet of Things" denotes a trend where a large number of 
devices employ communication services offered by the Internet 
protocols. Many of these devices are not directly operated by 
humans, but exist as components in buildings or vehicles, or are 
spread out in the environment. There is a large variation in the 
computing power, available memory, (electrical) power, and 
communications bandwidth between different types of devices. 


Many of these devices offer a range of new possibilities or provide 
additional value for previously unconnected devices. Some devices 
have been connected using proprietary communication networks in the 
past but are now migrating to the use of the Internet Protocol suite 
in order to share the same communication network between all 
applications and to enable rich communications services. 


Much of this development can simply run on existing Internet 
protocols. For instance, home entertainment and monitoring systems 
often offer a Web interface to the end user. In many cases the new, 
constrained environments can benefit from additional protocols and 
protocol extensions that help optimize the communications and lower 
the computational requirements. Examples of currently ongoing 
standardization efforts targeted for these environments include the 
Constrained RESTful Environments (CORE), IPv6 over Low power WPAN 
(6LOWPAN), Routing Over Low power and Lossy networks (ROLL), and the 
Light-Weight Implementation Guidance (LWIG) working groups of the 
IETF. 
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This workshop explored the experiences of researchers and developers 
when considering the characteristics of constrained devices. 
Engineers know that many design considerations need to be taken into 
account when developing protocols and architecture. Balancing 
between the conflicting goals of code size, economic incentives, 
power consumption, usability, and security is often difficult, as 
illustrated by Clark et al. in "Tussle in Cyberspace: Defining 
Tomorrow’s Internet" [Tussle]. 


Participants at the workshop discussed the experience and approaches 
taken when designing protocols and architectures for interconnecting 
smart objects to the Internet. The scope of the investigations 
included constrained nodes as well as constrained networks. 


The call for position papers suggested investigating the area of 
integration with the Internet in the following categories: 


o Scalability 

o Power efficiency 

o Interworking between different technologies and network domains 
o Usability and manageability 

o Security and privacy 

The goals of the workshop can be summarized as follows: 


As many deployed smart objects demonstrate, running protocols like 
the Internet Protocol Version 4 [RFC0791] and Version 6 [RFC2460], 
the User Datagram Protocol (UDP) [RFC0768], the Transmission 
Control Protocol (TCP) [RFC0793], the Hypertext Transfer Protocol 
(HTTP) [RFC2616], etc., on constrained devices is clearly 
possible. Still, protocol designers, system architects, and 
developers have to keep various limitations in mind. The 
organizers were interested to discuss the experience with 
deploying IETF protocols in different constrained environments. 


Furthermore, the organizers were seeking to identify issues either 
where current implementers do not yet have solutions or where 
researchers predict potential issues. 


The workshop served as a venue to identify problems and to 
discover common interests that may turn into new work or into 
changes in direction of already ongoing work at the IETF and or 
the Internet Research Task Force (IRTF). 
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2 


Constrained Nodes and Networks 


The workshop was spurred by the increasing presence of constrained 
devices on the network. It is quite natural to ask how these 
limitations impact the design of the affected nodes. Note that not 
all nodes suffer from the same set of limitations. 


Energy constraints: 


Since wireless communication can be a large portion of the power 
budget for wireless devices, reducing unnecessary communication 
can significantly increase the battery life of a low-end device. 
The choice of low-power radio can also significantly impact the 
overall energy consumption, as can sleeping periodically, when the 
device is not in use. In some cases, these nodes will only wake 
periodically to handle needed communications. This constraint is 
quite in contrast to the "always on" paradigm found in regular 
Internet hosts. Even in the case of non-battery operated devices, 
power is a constraint with respect to energy efficiency goals. 


Bandwidth constraints: 


Various low-power radio networks offer only limited bandwidth, and 
show high packet loss as well as high link quality variability. 
The data transmission rates vary from 20 to 900 kilobits per 
second (e.g., in the case of IEEE 802.15.4). Nodes may be used in 
usually highly unstable radio environments. The physical-layer 
packet size may be limited (7100 bytes). 


Memory constraints: 


The amount of volatile and persistent storage impacts the program 
execution and has important implications for the functionality of 
the protocol stack. The Arduino UNO board, for example, provides 
a developer with 2 KB RAM and 32 KB flash memory (without any 
extensions, such as microSD cards). 


A system designer also needs to consider CPU constraints, which often 
relate to energy constraints: a processor with lower performance 
consumes less energy. As described later in this document, the 
design of the mainboard may allow certain components to be put to 
sleep to further lower energy consumption. In general, embedded 
systems are often purpose built with only the hardware components 
needed for the given task, while general-purpose personal computers 
are less constrained with regard to their mainboard layout and 
typically offer a huge number of optional plug-in peripherals to be 
connected. A factor that also has to be taken into consideration is 
the intended usage environment. For example, a humidity sensor 
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deployed outside a building may need to deal with temperatures from 
-50 degrees C to +85 degrees C. There are often physical size 
limitations for smart objects. While traditional mainboards are 
rather large, such as the Advanced Technology eXtended (ATX) design 
with a board size of 305 x 244 mm available in many PCs or the mini- 
ITX design typically found in home theater PCs with 170 x 170 mm, 
mainboard layouts for embedded systems are typically much smaller, 
such as the CoreExpress layout with 58 x 65 mm, or even smaller. In 
addition to the plain mainboard, additional sensors, peripherals, a 
power adapter/battery, and a case have to be taken into 
consideration. Finally, there are cost restrictions as well. 


The situation becomes more challenging when not only the hosts are 
constrained but also the network nodes themselves. 


While there are constantly improvements being made, Moore’s law tends 
to be less effective in the embedded system space than in personal 
computing devices: gains made available by increases in transistor 
count and density are more likely to be invested in reductions of 
cost and power requirements than into continual increases in 
computing power. 


3. Workshop Structure 


With the ongoing work on connecting smart objects to the Internet, 
there are many challenges the workshop participants raised in more 
than 70 accepted position papers. With a single workshop day, 
discussions had to be focused, and priority was given to those topics 
that had been raised by many authors. A summary of the identified 
issues are captured in the subsections below. 


3.1. Architecture 


A number of architectural questions were brought up in the workshop. 
This is natural, as the architectural choices affect the required 
technical solutions and the need for standards. At this workshop, 
questions regarding the separation of traffic, the need for profiling 
for application-specific domains, the demand for data-model-specific 
standardization, as well as the design choices regarding the layer at 
which functionality should be put were discussed and are briefly 
summarized below. 


3.1.1. One Internet vs. Islands 
Devices that used to be in proprietary or application-specific 
networks are today migrating to IP networks. There is, however, the 


question of whether these smart objects are now on the same IP 
network as any other application. Controlled applications, like the 
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fountains in front of the Bellagio hotel in Las Vegas that are 
operated as a distributed control system [Dolin], probably are not 
exchanging their control messages over the same network that is also 


used by hotel guests for their Internet traffic. The same had been 
argued for smart grids, which are described as follows in 
[SmartGrid]: 


A smart grid is a digitally enabled electrical grid that gathers, 
distributes, and acts on information about the behavior of all 
participants (suppliers and consumers) in order to improve the 
efficiency, reliability, economics, and sustainability of 
electricity services. 


The question that was raised during the workshop is, therefore, in 
what sense are we talking about one Internet or about using IP 
technology for a separate, "walled garden" network that is 
independent of the Internet? 


Cullen Jennings compared the current state of smart object deployment 
with the evolution of Voice over IP (VoIP): "Initially, many vendors 
recommended to run VoIP over a separate VLAN or a separate 
infrastructure. Nobody could imagine how to make the type of real- 
time guarantees, how to debug it, and how to get it to work because 
the Internet is not ideally suited for making any types of guarantees 
for real-time systems. As time went on, people got better at making 
voice work across that type of IP network. They suddenly noticed 
that having voice running on a separate virtual network than their 
other applications was a disaster. They couldn’t decide if a PC was 
running a softphone and whether it went on a voice or a data network. 
At that point, people realized that they needed a converged network 
and all moved to one. I wouldn’t be surprised to see the same happen 
here. Initially, we will see very separated networks. Then, those 
will be running over the same hardware to take advantage of the cost 
benefits of not having to deploy multiple sets of wires around 
buildings. Over time, there will be strong needs to directly 
communicate with each other. We need to be designing the system for 
the long run. Assume everything will end up on the same network even 
if you initially plan to run it in separate networks." 


It is clearly possible to let sensors in a building communicate 
through the wireless access points and through the same 
infrastructure used for Internet access, if you want to. Those who 
want separation at the physical layer can do so as well. What is 
important is to make sure that these different deployment 
philosophies do not force loss of interoperability. 
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The level of interoperability that IP accomplished fostered 
innovation at the application layer. Ralph Droms reinforced this 
message by saying: "Bright people will take a phone, build an 
application and connect it, with the appropriate security controls in 
place, to the things in my house in ways we have never thought about 
before. Otherwise, we are just building another telephone network." 


3.1.2. Domain-Specific Stacks and Profiles 


Imagine a building network scenario where a new light bulb is 
installed that should, out of the box without further configuration, 
interoperate with the already present light switch from a different 
vendor in the room. For many, this is the desired level of 
interoperability in the area of smart object design. To accomplish 
this level of interoperability, it is not sufficient to provide 
interoperability only at the network layer. Even running the same 
transport protocol and application-layer protocol (e.g., HTTP) is 
insufficient since both devices need to understand the semantics of 
the payloads for "Turn the light on" as well. 


Standardizing the entire protocol stack for this specific "light 
switch / light bulb" scenario is possible. A possible stack would, 
for example, use IPv6 with a specific address configuration mechanism 
(such as stateless address autoconfiguration), a network access 
authentication security mechanism such as Protocol for carrying 
Authentication for Network Access (PANA) [RFC5191], a service 
discovery mechanism (e.g., multicast DNS with DNS-Based Service 
Discovery [DNS-SD]), an application-layer protocol, for example, 
Constrained Application Protocol (CoAP) [CoAP] (which uses UDP), and 
the syntax and semantic for the light on/off functionality. 


As this list shows, there is already some amount of protocol 
functionality that has to be agreed on by various stakeholders to 
make this scenario work seamlessly. As we approach more complex 
protocol interactions, the functionality quickly becomes more 
complex: IPv4 and IPv6 on the network layer, various options at the 
transport layer (such as UDP, TCP, the Stream Control Transmission 
Protocol (SCTP) [RFC4960], and the Datagram Congestion Control 
Protocol (DCCP) [RFC4340]), and there are plenty of choices at the 
application layer with respect to communication protocols, data 
formats and data models. Different requirements have led to the 
development of a variety of communication protocols: client-server 
protocols in the style of the original HTTP, publish-subscribe 
protocols (like the Session Initiation Protocol (SIP) [RFC3261] or 
Extensible Messaging and Presence Protocol (XMPP) [RFC6121]), and 
store-and-forward messaging (borrowed from the delay tolerant 
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networking community). Along with the different application-layer 
communication protocols come various identity and security 
mechanisms. 


With the smart object constraints, it feels natural to develop these 
stacks since each application domain (e.g., healthcare, smart grids, 
building networking) will have their unique requirements and their 
own community involved in the design process. How likely are these 
profiles going to be the right match for the future, specifically for 
the new innovations that will come? How many of these stacks are we 
going to have? Will the differences in the profiles purely be the 
result of different requirements coming from the individual 
application domains or will these mismatches reflect the spirit, 
understanding, and preferences of the community designing them? How 
many stacks will multipurpose devices have to implement? 


Standardizing profiles independently for each application is not the 
only option. Another option is to let many different applications 
utilize a common foundation, i.e., a protocol stack that is 
implemented and utilized by every device. This, however, requires 
various application domains to be analyzed for their common 
characteristics and to identify requirements that are common across 
all of them. The level of difficulty for finding an agreement of how 
such a foundation stack should look depends on how many layers it 
covers and how lightweight it has to be. 


From the discussions at the workshop, it was clear that the available 
options are not ideal and further discussions are needed. 


3.1.3. Which Layer? 


The end-to-end principle states that functionality should be put into 
the end points instead of into the networks. An additional 
recommendation, which is equally important, is to put functionality 
higher up in the protocol stack. While it is useful to make common 
functionality available as building blocks to higher layers, the wide 
range of requirements by different applications led to a model where 
lower layers provide only very basic functionality and more 
sophisticated features were made available by various applications. 
Still, there has been the desire to put application-layer 
functionality into the lower layers of the networking stack. A 
common belief is that performance benefits can be gained if 
functionality is placed at the lower layers of the protocol stack. 
This new functionality may be offered in the form of a gateway, which 
bridges different communication technologies, acts on behalf of other 
nodes, and offers more generic functionality (such as name-based 
routing and caching). 
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Two examples of functionality offered at the network layer and 
discussed during the workshops were location and name-based routing: 


Location: 


The notion of location gives each network node the understanding 
of proximity (e.g., ’I am a light bulb and in the same room as the 
light switch.’). Today, a router may provide information as to 
whether other nodes belong to the same subnet or they may provide 
location information (for example, in the form of GPS-based 
coordinates). However, providing a sense of the specific 
environment (e.g., a room, building, campus, etc.) is not possible 
without manual configuration. While it has been a desirable 
feature for many ubiquitous computing applications to know this 
type of information and to use it for richer application-layer 
interactions, widespread deployment has not happened yet. 


Name-Based Routing: 


With the work on recent "clean slate" architecture proposals, such 
as named data networking, flexible naming concepts are being 
researched to allow application developers to express their 
application-layer concepts in a way that they can be used natively 
by the underlying networking stack without translation. For 
example, Jeff Burke provided the example of his work in a theater 
with a distributed control system of technical equipment (such as 
projectors, dimmers, and light systems). Application developers 
name their equipment with human-readable identifiers, which may 
change after the end of a rehearsal, and address them using these 
names. These naming concepts based on variable-length strings 
raise questions regarding scalability. 


The workshop participants were not able to come to an agreement about 
what functionality should be moved from the application layer to the 
network layer. 


3.2. Sleeping Nodes 


One limitation of smart objects is their available energy. To extend 
battery life, for example, of a watch battery or single AAA battery 
for months, these low-power devices have to sleep 99% to 99.5% of 
their time. For example, a light sensor may only wake up to check 
whether it is nighttime to turn on light bulbs. Most parts of the 
system, particularly communication components, are put into a 
sleeping state (e.g., WLAN radio interface) and selected components, 
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such as sensors, periodically check for relevant events and, if 
necessary, turn on other hardware modules. Every bit is precious, as 
is every round trip and every millisecond of radio activity. 


Many IETF protocols are implicitly designed to be always on, i.e., 
the protocol implementation waits for and reacts to incoming 
messages, and may maintain session state (at various layers of the 
stack). These protocols work well when energy consumption is not a 
concern and when receiving and sending messages happen at a low cost. 
It should be understood that energy is consumed both in transmitting 
messages (and often more importantly) in keeping the receiver awake. 
Allowing devices to sleep most of the time preserves energy but 
creates challenges for protocol designs. 


The inherent issue encountered by a stationary node resuming from 
sleep is that another node may have chosen the same address while the 
node was asleep. A number of steps have to be taken before sending a 
packet. A new address may have to be obtained, for example using the 
Dynamic Host Configuration Protocol (DHCP) or stateless address 
autoconfiguration. Optionally, Detecting Network Attachment (DNA) 
procedures (see [RFC4436] and [RFC6059]) can be used to shorten the 
setup time by noticing that the node is using the same default 
gateway. 


The issue with a mobile node that is sleeping is that the node may 
have been moved to another network (e.g., a sleeping laptop being 
transported to a new environment) where on resumption it may discover 
that its address has become invalid. 


The following design considerations should be taken into account when 
energy efficiency is a concern: 


1. Rethink the Always-On Assumption 


When designing a protocol that assumes that the nodes are always 
on, alternatives need to be considered. This could involve 
eliminating functionality (e.g., not implementing DNA or 
duplicate address detection) or considering the use of a sleep 
proxy. While sleep proxies (e.g., proxZzzy(TM) [proxZzzy]) 
enable periodic messages to be sent on behalf of sleeping nodes, 
this approach assumes that energy management constraints do not 
apply to the sleep proxy, which may not always be the case (e.g., 
if the entire network is deployed in the field without access to 
power). Yet another option is for devices to explicitly 
communicate sleep cycles so that they can only check for messages 
periodically (be it measured in milliseconds, seconds, or hours). 
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This is the approach taken in IEEE 802.11, which supports 
multiple energy conservation mechanisms designed to enable a 
station to spend a large fraction of the time sleeping. 


2. Reduce Network Attachment Costs 


As noted above, the procedures for obtaining an address and 
assuring its uniqueness can be costly. In a network where nodes 
spend a large fraction of the time sleeping, but are not 
necessarily mobile, are all of these procedures really necessary? 


Can we find ways to reduce the number of protocol interactions 
without sacrificing correctness? The main focus of past 
investigations has been on IPv6 and ND, but other protocols do 
also deserve a deeper investigation, such as DNS and DHCP. 


3. Avoid Verbose Protocols 


Protocols involving multiple roundtrips and/or lengthy messages 
with verbose encodings (e.g., XML) are not always well-suited for 
constrained environments. Low-power nodes utilizing verbose 
protocols have to use more energy in sending messages and have to 
stay powered on for a longer period of time as they wait for the 
multi-roundtrip protocol exchanges to complete. 


The best way to address these problems is to ensure that the 
simplest possible protocol exchanges are used when the protocols 
in question are designed. In some cases, alternative encoding 
formats and compression may also help. 


4. Think about System-Wide Efficiency 


While energy efficiency is critical for low-power devices running 
on batteries, it is also beneficial for other devices as well, 
including notebook computers, desktop computers, and smartphones. 
However, if the goal is energy efficiency as opposed to battery 
life extension for low-power devices, then it is important to 
consider the total energy consumption of all the elements of the 
system. 


For example, consider energy consumption in a home environment. 
In these scenarios it is important to evaluate the energy usage 
of the entire system. A light bulb utilizing Internet technology 
described in this document may use less power but there is also 
the device that controls the bulb that may consume a lot of 
energy. If the goal is to reduce overall energy usage, then it 
is important to consider these two devices (and potentially many 
others) together. 
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3.3. Security 


In the development of smart object applications, as with any other 
protocol application solution, security has to be considered early in 
the design process. As such, the recommendations currently provided 
to IETF protocol architects, such as RFC 3552 [RFC3552] and RFC 4101 
[RFC4101], apply also to the smart object space. 


While there are additional constraints, as described in Section 2, 
security has to be a mandatory part of the solution. The hope is 
that this will lead to implementations that provide security 
features, deployments that utilize them, and finally use of better 
security mechanisms. It is important to point out that the lack of 
direct user interaction will place hard requirements on deployment 
models, configuration mechanisms, and software upgrade / 
crypto-agility mechanisms. 


Since many of the security mechanisms allow for customization, 
particularly with regard to the cryptographic primitives utilized, 
many believe that IETF security solutions are usable without 
modifications in a large part of the smart object domain. Others 
call for new work on cryptographic primitives that make use of a 
single primitive (such as the Advanced Encryption Standard (AES) 
[AES]) as a building block for all cryptographic functions. The 
benefit would be a smaller footprint of the overall solution, 
specifically with respect to hardware limitations (e.g., the hardware 
architecture of certain embedded devices prevents pipelining from 
being used). In the excitement for new work on optimizations of 
cryptographic primitives, other factors have to be taken into 
consideration that influence successful deployment, such as 
widespread support in libraries, as well as intellectual property 
rights (IPR). As an example of the latter aspect, the struggle of 
Elliptic Curve Cryptography (ECC)-based cryptographic algorithms 
[ECC] to find deployment can partially be attributed to its IPR 
Situation. The reuse of libraries providing cryptographic functions 
is clearly an important way to use available memory resources in a 
more efficient way. To deal with the performance and footprint 
concerns, investigations into offloading certain resource-hungry 
functions to parties that possess more cryptographic power have been 
considered. For example, the ability to delegate certificate 
validation to servers has been standardized in the IETF before, for 
the support of the Online Certificate Status Protocol (OCSP) in the 
Internet Key Exchange protocol version 2 (IKEv2) and in Transport 
Layer Security (TLS); see [RFC4806] and [RFC5246], respectively. 


Focusing only on the cryptographic primitives would be shortsighted; 
many would argue that this is the easy part of a smart object 
security solution. Key management and credential enrollment, 
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however, are considered a big challenge by many, particularly when 
usability requirements have to be taken into account. Another group 
of challenges concern privacy; with smart grids, for example, some 
have voiced concerns regarding the ability of third parties to keep 
track of an individual’s energy consumption (and draw associated 
conclusions). As another example, it is easy to see how a scale that 
is connected to the Internet for uploading weight information to a 
social network could lead to privacy concerns. While security 
mechanisms that are used to offer protection of the communication 
between different parties also provide a certain degree of privacy 
protection, they are clearly not enough to address all concerns. 
Even with the best communication security and access control 
mechanisms in place, one still needs additional safeguards against 
the concerns mentioned in the examples. 


While better deployment of security protocols on the entire Internet 
would be very desirable, practical considerations regarding usability 
and the incentives of the stakeholders involved have often lead to 
slower adoption. 


3.4. Routing 


A smart object network environment may also employ routers under 
similar constraints as the end devices. Currently two approaches to 
routing in these low-power and lossy networks are under consideration 
-- namely, mesh-under and route-over. The so-called "mesh-under" 
approach places routing functions at the link layer, and consequently 
all devices appear as immediate neighbors at the network layer. With 
the "route-over" approach, routing is done in the IP layer and not at 
all in the link layer. Each physical hop appears as a single IP hop 
(ignoring devices that just extend the physical range of signaling, 
such as repeaters). Routing in this context means running a routing 
protocol. The IPv6 Routing Protocol for Low-power and Lossy Networks 
(RPL) [RPL], for example, belongs to the route-over category. 


From an architectural point of view there are several questions that 
arise from where routing is provided, for example: 


o Protocols often assume that link characteristics are predictable 
when communicating with any device attached to the same link. 
Latency, throughput, and reliability may vary considerably between 
different devices that are multiple link-layer hops away. What 
timeout should be used? What happens if a device is unreachable? 
In case of default router selection, two advertised routers may be 
a different number of hops away. Should a device have visibility 
into the path to make a decision, and what path characteristics 
would be useful to have? 
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o Scoped message delivery to a neighboring IP hop (via link-local 
addressing) allows certain types of IP protocols to communicate 
with their immediate neighbors and to therefore scope their 
recipients. A link-local multicast message will be received by 
all nodes in the same IP link-local realm unless some special 
optimizations are provided by the link layer. 


o When path computations are done at the link layer as well as on 
the network layer, then what coordination needs to take place? 


When multiple different link-layer technologies are involved ina 
network design, routing at layer 3 has to be provided in any case. 
[IoT-ARCH] talks about these tradeoffs between route-over and mesh- 
under in detail. Furthermore, those who decide about the deployment 
have to determine how to connect smart objects to the Internet 
infrastructure, and a number of wired and wireless technologies may 
be suitable for a specific deployment. Depending on the chosen 
technologies the above-mentioned mesh-under vs. route-over approach 
will have to be decided, and further decisions will have to be made 
about the choice of a specific routing protocol. 


In 2008, the IETF formed the Routing Over Low power and Lossy 
networks (ROLL) working group to specify a routing solution for smart 
object environments. During its first year of existence, the working 
group studied routing requirements in detail (see [RFC5867], 
[RFC5826], [RFC5673], and [RFC5548]), and it worked on a protocol 
survey comparing a number of existing routing protocols, including Ad 
hoc On-Demand Distance Vector (AODV)-style protocols [RFC3561], 
against the identified requirements. The protocol survey 
[PROT-SURVEY] was inconclusive and abandoned without giving rise to 
publication of an RFC. 


The ROLL WG concluded that a new routing protocol satisfying the 
documented requirements has to be developed and the work on RPL was 
started as the IETF routing protocol for smart object networks. 
Nevertheless, controversial discussions at the workshop about which 
routing protocols is best in a given environment are still ongoing. 
Thomas Clausen, for example, argued for using an AODV-like routing 
protocol in [Clausen]. 
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4. 


Conclusions and Next Steps 


The workshop allowed the participants to be exposed to interesting 
applications and their requirements (buildings, fountains, theater, 
etc.), to have discussions about radically different architectures 
and their issues (e.g., information centric networking), to look at 
existing technology from a new angle (sleeping nodes, energy 
consumption), to focus on some details of the protocol stack 
(neighbor discovery, security, routing) and to learn about 
implementation experience. 


One goal of the workshop was to identify areas that require further 

investigation. The list below reflects the thoughts of the workshop 
participants as expressed on the day of the workshop. Note that the 
suggested items concern potential work by the IETF and the IRTF, and 
the order does not imply a particular preference. 


Security: 


A discussion of security is provided in Section 3.3. In general, 
security-related protocol exchanges and the required amount of 
computational resource requirements can contribute significantly 
to the overall processing. Therefore, it remains a challenge to 
accomplish performance improvements without sacrificing the 
overall security level, taking the usability of the entire system 
into consideration. 


Another challenge is how to balance the security and performance 
needs of smart objects with the interoperability requirements of 
hosts on the Internet since different suites of algorithms tend to 


be chosen for these different environments. This involves trade- 
offs between performance on the smart objects versus end-to-end 
security. Solutions that mandate a "trusted" middlebox whose only 


role is to terminate security associations tend to be frowned upon 
from the security perspective, especially since end users of 
challenged devices (where those exist) are unlikely to understand 
the security consequences of such middleboxes. 


The discussion concluded with the following recommendations: 


* Investigate usability in cryptographic protocol design with 
regard to credential management. As an example, the Bluetooth 
pairing mechanism was mentioned as a simple and yet reasonably 
secure method of introducing devices into a new environment. 
In fact, the IETF working group Credential and Provisioning 
(ENROLL) was established years ago to deal with residential 
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networks but was terminated prematurely due to lack of 
progress. The email archive still exists and is available 
[ENROLL] and may provide useful historical information. 


* Standardized authentication and key exchange mechanisms should 
be surveyed for suitability in smart object environments with 
respect to message size, computational performance, number of 
messages, code size, and main memory requirements. A starting 
point of such an investigation (in the case of IKEv2) was 
provided by Tero Kivinen with [MINIMAL-IKEv2], and a suitable 
venue for discussion could be the recently established Light- 
Weight Implementation Guidance (LWIG) working group [LWIG]. 


* Research has to be done in the area of lightweight 
cryptographic primitives -- namely, block ciphers, stream 
ciphers, and cryptographic hash functions. It’s worthwhile to 
mention the early work with the National Institute of Standards 
and Technology (NIST) new cryptographic hash algorithm ’ SHA-3’ 
competition [SHA3]. A suitable forum for discussion is the 
IRTF Crypto Forum Research Group (CFRG) [CFRG]. 


The difficulty and impact of choosing specialized algorithms for 
smart objects should not be underestimated. Issues that arise 
include the additional specification complexity (e.g., TLS already 
has hundreds of ciphersuites defined, most of which are unused in 
practice), the long latency in terms of roll out (many hosts are 
still using deprecated algorithms 5-10 years after those 
algorithms were deprecated), and the barriers that IPR-encumbered 
schemes present to widespread deployment. While research on this 
topic within CFRG and the cryptographic research community is a 
very worthwhile goal, any such algorithms will likely have to 
offer very significant benefits before they will be broadly 
adopted. 20% less CPU usage is unlikely to be a winning argument 
no matter what an algorithm inventor believes. 


Energy Design Considerations: 


One part of the workshop was focused on the discussion of energy 
implications for IETF protocol design with proposals being made 
about how to extend protocols to better support nodes that are 
mostly sleeping. Discussions are encouraged to take place on the 
RECIPE mailing list [RECIPE]. The workshop position paper 
[Wasserman] by Margaret Wasserman provides a good starting point 
for further investigations. 
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Information-/Content-Centric Networking: 


Information/Content Centric Networking is about accessing named 
content, and a number of research projects have emerged around 
this theme. At this point in time, the work is not yet ready for 
standardization in the IETF. Instead, the formation of an IRTF 
research group has been proposed, and more details are available 
on the IRTF DISCUSS mailing list [irtf-discuss]. 


Architectural Guidelines: 


Participants suggested developing an architectural write-up about 
what can be done with the IETF protocols we have today and how 
these different elements may be combined to offer an explanation 
for the broader community. This would be a task for the IAB. An 
example of prior work that serves as input is [RFC6272]. 


Network Management: 


While this topic did not make it onto the workshop agenda, it was 
considered useful to start a discussion about how to implement 
network management protocols, such as Network Configuration 
Protocol (NETCONF) [RFC6241], on smart objects. The following 
position papers may be useful as a starting point for further 
discussions: [Ersue] and [Schoenwaelder]. An IETF draft document 
is also available: [SNMP-OPT]. 


Congestion Control: 


When smart objects transmit sensor readings to some server on the 
Internet, these protocol interactions often carry a small amount 
of data and happen infrequently, although regularly. With the 
work on new application protocols, like CoAP [CoAP], the question 
of whether a congestion control mechanism should be used at the 
underlying transport protocol or by the application protocol 
itself arises. [CoAP-CC] is a starting point for CoAP, but 
further work is needed. 


Data Models: 


Standardization of application-layer protocols is important but 
does not ensure that, for example, a light switch and a light bulb 
are able to interact with each other. One area where participants 
saw the need for further work was in the area of data models. 
While prior IETF standardization work on, for example, location 
[GEOPRIV] can be reused, the question was raised where the IETF 
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should focus its standardization efforts since domain expertise in 
each area will be needed. As a potential example, energy pricing 
was discussed, with an example provided by [ENERGY-PRICING]. 


Building Networking: 


Network architectures in residential as well as commercial 
buildings should take the presence of smart objects and dedicated 
subnetworks focusing on smart objects into account. A new working 
group, Home Networking (HOMENET) [HOMENET], was created after the 
workshop to look at this topic. 


Discovery: 


Additional extensions to developed discovery protocols, such as 
multicast DNS (mDNS), may be needed for the smart object 
environment. For instance, the HOMENET working group wants to 
extend current discovery protocols to work across multiple 


subnets. Smart object networks are often organized in separate 
subnets, so these extensions may be useful in that environment as 
well. 

Routing: 


Changing radio conditions and link fluctuation may lead to the 
need for renumbering. Workshop participants argued that work 
should be started on the multi-link subnetworks to mitigate this 
problem, i.e., to extend the notion of a subnet to be able to span 
multiple links. With the publication of RFC 4903 [RFC4903], the 
Internet Architecture Board had looked into this topic already and 
provided pros and cons. 


The applicability of specific routing protocols designed for smart 
object networks needs further investigation. The ROLL working 
group is chartered with the task of constructing an applicability 
document for RPL, for instance. 


5. Security Considerations 
The workshop discussions covered a range of potential engineering 
activities, each with its own security considerations. As the IETF 
community begins to pursue specific avenues arising out of this 


workshop, addressing relevant security requirements will be crucial. 


As described in this report, part of the agenda was focused on the 
discussion of security; see Section 3.3. 
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